[レポート] ゲームのバックエンドを支えるスケーラブルかつ柔軟な AWS でのインフラ構築 #AWSSummit

5/30 から 6/1 まで、東京・品川で開催されております AWS Summit Tokyo 2018。こちらで講演されたセッション「AWS を使った動画配信入門」を聴講しましたのでレポートします。

AWS Summit Tokyo 2018

#イベントレポート

#レポート

#AWS

#ゲーム開発・運用

渡辺聖剛

2018.06.06

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

5/30 から 6/1 まで、 AWS Summit Tokyo 2018 が東京・品川で開催されました。こちらで講演されたセッション「ゲームのバックエンドを支えるスケーラブルかつ柔軟な AWS でのインフラ構築」を聴講しましたのでレポートします。

今回のAWS Summitでは全セッションにて撮影が禁止されておりました。資料は後ほど公開されるとは思いますが、いまのところは文字だけのご報告となります。

概要

近年、ゲーム市場において PC、モバイル、コンソールと多様化しており、ゲームのネットワーク接続が当たり前になってきています。本セッションでは、ゲームのバックエンドで高トラフィックなインフラを AWS 上で、どのように構築し運用するか、またゲームの分析基盤などの構築について事例を交えてご紹介します。

スピーカ

森祐孝
- アマゾンウェブサービスジャパン株式会社技術統括本部ソリューションアーキテクト
- 担当 : ソーシャルゲーム、コンソール系ゲーム会社

※敬称略

レポート

「ゲームの開発は楽しい」
- しかし…
- 長い時間をかけて開発し、リリースした瞬間に「サーバーエラー」
  - わび石、延期、、、
ゲームのリリースの準備は大丈夫か？？
- メディアのレビュー
- ユーザ評価
- アプリストアのフィーチャリング（お勧め）
- 想定した最悪のシナリオ の 50 倍 のアクセスが来たりもする
ユーザの需要に合わせてサーバをスケール
- 過剰なキャパシティ、無駄な投資
- 需要に対応できない、ゲームプレイヤーに不満
従来 : Rigid
AWS : Elastic

インフラはどう作るか

アンチパターン = モノリシック
- 認証モジュールなどはリリース・メンテ明けに急に負荷が高くなる、他がそこに引きづられる
アンチパターン = モノリシックスケーリング
- モノリシックなサーバをそのまま並列（スケールアウト）
- ユーザが増えれば、マッチメイキングやマルチプレイヤーロジックなどがネックとなる
サービス指向のアーキテクチャ
- モジュールを分割
  - API化してサーバを分ける
  - モジュールごとに開発、OSを変更することすらできる
- 認証 -> マッチメイキング間の通信
  - 認証に規模が必要 -> 認証モジュールだけを負荷分散（ELB追加）
  - マッチメイキングの前にELBを置くことも可能
  - 必要に応じてバラバラに構築・スケールを考えることができる
- 一番弱いところのスループットに全体が引っ張られる
  - -> 弱いところの前段にキューを追加 = SQS
- ELB -> 認証 -> SQS -> マッチメイキング
  - = イベント駆動アーキテクチャ
基本的なゲームバックエンドサーバのコンセプト
- クライアントとの通信はAPI経由
- HTTP + JSON、gRPC
- フレンドリスト、リーダボード
- バイナリアセットデータ
- マルチプレイヤー
- 高可用性
- 拡張性
S3 + CloudFront
- アセット、DLC、セーブデータ
マルチプレイヤーゲームサーバ
- ダイレクトソケット
ゲームAPIバックエンドサーバ
- 認証、マッチメイキング
- 最適なリージョンを選択
- 2つ以上のAZ
- アプリ用EC2
- ELB
- Amazon RDS (MySQL, MariaDB, Aurora...)
  - Multi-AZ
  - 最近だとAuroraを使う案件が増えている（ゲームのワークロードに適している）
スケールアウト！
- S3 ゲームデータ格納
  - ゲームデータ、アセット、ログや分析データ
- CloudFront コンテンツ配信
- Auto Scaling Group
- ElastiCache (Memcached, Redis)
ElasticCache(Redis)をつかったチャット、リーダーボード、ランキングボード
マネージドサービスを用いたデータのキャッシュ方法
- RDSのストアドプロシジャを使ってLambdaを起動、DynamoDBを参照しS3へ

データベース

DBの更新頻度が課題に
- ゲームはライト(write)ヘビー
シャーディングはつらい。。。
- データのJOINが難しい
- データの集計でDBをまたぐ
- オートインクリメントが使えない
解決策 : DynamoDB
- フルマネージド
- NoSQLデータストア、容量無制限
- プロビジョンドスループット
- セカンダリインデクス
- PUT/GET Keys
- TTLサポート
- ドキュメント型のサポート
- 400KBアイテム
- PITRサポート
- DynamoDB Accelerator（Cache）
DynamoDBはゲームに向いている
- ユーザデータをDynamoDBで管理
- Partition Key に UserIDを使用
- スキーマレス（カラムを増やすことも簡単）
- TTLを活用、いらなくなったデータを削除
DynamoDBをつかったマイクロサービス構成
- QueryとOLTPを分ける

API

API Gateway
マルチプレイヤーゲームサーバ
- APIを使ったログイン
- マッチメイキング
- ゲームサーバのIPを取得
gRPCを使ったAPI接続の注意点
- ALB とバックエンド間の通信はHTTP/1.1になる = gRPCは使えない
- NLBを推奨

事例・その他

事例 - 株式会社グラニ
- 2系統のgRPC
  - WebAPIの役割のステートレスなgRPC
  - 詳細は去年の事例を参照のこと (AWS Summit Tokyo 2017）
    - 「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践
- イベント駆動アーキテクチャへ
- Amazon SNSをもちいたPUSHメッセージ
  - プレイヤー間のメッセージのやりとりを実装
グローバル展開
- 適したリージョンに構築、バックエンドはリージョン間通信
- 事例 : PUBG
  - 全ての非同期メッセージング処理はSQS
- Nexon
  - Echo System Simulator
    - 植生のシミュレーションを非同期で実行
- CloudFrontのGeoIPで適したAPIへ誘導
- DynamoDB Global Tables
  - フルマネージド、マルチマスター、マルチリージョンデータベース
Game Analytics
- S3を中心としたデータレイク
  - 分析、バックアップ、BI、機械学習　etc
  - 事例 : ユーザがゲーム内でどこで死んだかを分析、ゲームマップを改善
    - ヒートマップ表示
    - Kinesis + Redshift
Gaming Analytics Pipeline – AWS Answers
- 実績ある分析プラットフォームをワンクリックで構築